PROJETO DE 
BANCO DE DADOS 
MODELAGEM CONCEITUAL 


DEFINIÇÃO 


Descrição das etapas de um projeto de banco de dados e dos componentes de um diagrama 
de entidade e relacionamento, além da modelagem de entidades e relacionamentos e de 


atributos. 


PROPÓSITO 


Identificar as etapas de um projeto de banco de dados a fim de destacar a importância da 
modelagem conceitual com o uso de diagrama de entidade e relacionamento, atividade comum 


aos profissionais da área de análise de negócio e administração de dados. 


PREPARAÇÃO 


É recomendável que você reproduza os exemplos práticos usando uma ferramenta para 


modelagem de dados como a brModelo, que pode ser baixada gratuitamente para essa tarefa. 


OBJETIVOS 


MÓDULO 1 


Identificar as etapas de um projeto de banco de dados 


MÓDULO 2 


Reconhecer os elementos do diagrama de entidade e relacionamento 


MÓDULO 3 


Compreender a modelagem de entidades e relacionamentos 


MÓDULO 4 


Compreender a modelagem de atributos 


INTRODUÇÃO 


Queremos construir um banco de dados. Por onde começamos? 


Em primeiro lugar, é necessário esclarecer que, ao construirmos um banco de dados, estamos 
automatizando algum tipo de negócio, ou mesmo parte dele. Segundo Elmasri e Navathe 
(2019), um banco de dados representa algum aspecto do mundo real, às vezes chamado 
de minimundo ou de universo de discurso. É fundamental conhecermos como o negócio 


funciona. 


Veremos, neste tema, que a construção de um banco de dados é uma atividade dividida em 
fases bem definidas. Ao longo delas, costumamos usar modelos de dados, que servem para 
que o usuário tenha facilidade para entender a organização da estrutura do banco de dados 
sendo construído. Perceberemos que isso ocorre porque o modelo não possui informações 


muito detalhadas a respeito da representação física dos dados. 


A etapa de projeto conceitual servirá para a construção de diagrama de entidade e 
relacionamento (DER), em que há dois conceitos essenciais: entidades e relacionamentos. 
Trabalharemos alterações em um DER com objetivo de comportar novos requisitos de dados e 
perceberemos que a construção desse diagrama é um processo incremental e sempre sujeito a 


revisões. 


No último módulo, voltaremos nossa atenção para a modelagem de atributos para fecharmos o 


nosso ciclo de aprendizagem. 


MÓDULO 1 


(9 Identificar as etapas de um projeto de banco de dados 


PROJETO DE BANCO DE DADOS 


Projetar um banco de dados, de maneira simplificada, envolve as seguintes fases: 


levantamento de requisitos, projeto conceitual, projeto lógico e projeto físico. 


Ao construir um banco de dados para alguma corporação, devemos ter em mente que há 


colaboradores desempenhando diversas tarefas associadas ao negócio em questão. 


Assim, temos que adquirir conhecimento sobre o funcionamento das rotinas e tarefas para 


capturarmos as necessidades associadas à gestão de dados. Veremos que esse conhecimento 


ocorre na fase de levantamento de requisitos. 


Fonte: Shutterstock 


LEVANTAMENTO DE REQUISITOS 


Ao longo da etapa de levantamento de requisitos, o profissional de dados entrevista usuários 
para entender sobre o funcionamento do negócio e documentar os requisitos de dados de 
maneira completa e detalhada. Depois disso, pode dar início à próxima etapa: o projeto 


conceitual. 


ft EXEMPLO 


Imagine que você foi convidado a participar de um projeto que objetiva construir um banco de 
dados para controlar inscrições de alunos em uma escola de treinamentos na área de 
Tecnologia de Informação. Após realizar entrevistas junto aos colaboradores, você identifica os 


seguintes requisitos de dados da escola: 


A escola planeja diversos cursos. Cada um deles possui nome, descrição, carga horária e 


é identificado por um código único. 


A escola armazena o nome, a data de nascimento, o CPF, o e-mail e um telefone de cada 


cliente, que é identificado por um código único. 


Quando um cliente faz inscrição em determinado curso, é necessário que se armazene a 
data. Caso seja cancelada a inscrição, é preciso saber quando ocorreu esse evento. Um 


cliente pode fazer diversos cursos. 


Com os requisitos de dados em mãos, usaremos um modelo de dados gráfico para formalizar 
entendimento mais preciso a respeito dos requisitos de dados. Essa atividade ocorrerá na 


próxima fase do projeto de banco de dados: projeto conceitual. 


PROJETO CONCEITUAL 


O projeto ou esquema conceitual envolve construir um modelo de dados de alto nível a partir 
dos requisitos de dados que contêm os principais objetos e seus relacionamentos, mapeados 
na etapa de levantamento de requisitos. Nesta etapa, não há preocupação em saber detalhes 


sobre como os dados devem ser armazenados. 


O projeto conceitual usa um diagrama gráfico, conhecido por Diagrama de Entidade e 
Relacionamento (DER), que possui três elementos essenciais: entidades, relacionamentos 
e atributos. Em um DER, cada entidade é representada por um retângulo com o seu nome. De 
forma semelhante, cada relacionamento, por um losango ligado por linhas aos retângulos das 


entidades participantes do relacionamento. 


Os atributos são expressos graficamente ligados à entidade ou ao relacionamento ao qual 
fazem parte. A Figura 1 representa um DER construído a partir dos requisitos de dados obtidos 


na etapa de levantamento de requisitos. 


IDCURSO 


IDCLIENTE 


CLIENTE 


(O NOME 


(O DATACANCELAMENTO 


(O CARGAHORARIA 


(O DESCRICAO 


(O DATAINSCRICAO () NOME 


(O DATANASCIMENTO 
(O TELEFONE 
(O EMAIL 


Fonte: Elaboração do autor 


& Figura 1 —- DER construído a partir dos requisitos de dados da Escola. 


A partir desse diagrama, é possível concluir que o modelo possui duas entidades (CLIENTE e 
CURSO) cuja função é armazenar os dados dos clientes e dos cursos da escola. Além disso, 
essas entidades possuem uma relação entre si, de maneira que um cliente pode fazer inscrição 


em um ou mais cursos. 


[...] O ESQUEMA CONCEITUAL DE ALTO NÍVEL (DER) 
PODE SER UTILIZADO COMO UMA REFERÊNCIA PARA 
GARANTIR QUE TODOS OS REQUISITOS DE DADOS 
DOS USUÁRIOS SEJAM ATENDIDOS E QUE NÃO 
ESTEJAM EM CONFLITO. 


(ELMASRI; NAVATHE, 2019) 


Isso acontece porque a representação dos requisitos de dados a partir do DER permite um 
aprendizado mais preciso a respeito do funcionamento do negócio sendo modelado, quando 


comparado aos requisitos de dados. 


OUTRA NOTAÇÃO PARA DER: DIAGRAMA DE 
CLASSES UML 


Ao longo da sua atuação profissional, você perceberá que não há uma notação-padrão para 
representação dos conceitos do modelo de entidade e relacionamento. Normalmente, a 
notação depende de preferência dos profissionais ou mesmo de regras estabelecidas pela 
empresa de desenvolvimento. As ferramentas CASE fazem uso de várias notações. Por 
exemplo, a utilizada na ferramenta brModelo é muito próxima da notação original para modelos 


de entidade e relacionamento. 


Em projetos de software, é comum o uso da UML para visualização e documentação dos seus 
componentes. De certa forma, um diagrama de classes da UML pode ser considerado uma 
notação alternativa para representar os conceitos de um DER. No diagrama de classes UML, 


cada classe é representada por uma caixa que possui três seções: 


SUPERIOR 


Exibe o nome da classe. 


CENTRAL 


Exibe os atributos. Além disso, o desenvolvedor pode, se desejar, adicionar informações sobre 


o tipo de dados de algum atributo, colocando um sinal de dois pontos “:” e em seguida o nome 


do tipo de dados. 


INFERIOR 


Inclui as operações associadas aos objetos da classe, a serem designadas numa etapa 


posterior, quando do projeto das aplicações do banco de dados. 


Na terminologia da UML, o relacionamento entre classes é chamado de associação. Assim, 
uma associação é representada por uma linha que conecta as classes participantes. Além 
disso, atributos dos relacionamentos são colocados em uma caixa conectada à associação por 
uma linha tracejada. A Figura 2 mostra como o DER construído a partir dos requisitos de dados 


da escola pode ser exibido sob a forma de diagrama de classes UML. 


nome: string 


datanascimento: date nome: string 
cpf:string descricao: string 
email: string ahoraria:int 


telefone:strino 


datainscricao: date 
datacancelamento: date 


Fonte: Elaboração do autor 


(3 Figura 2 —- Esquema conceitual Escola na notação do diagrama de classes UML. 


Após as etapas de levantamento de requisitos e criação do DER, estamos quase prontos para 
conhecermos a construção do banco de dados propriamente dito. Construiremos um modelo 
de dados de mais baixo nível, que vai depender da escolha do SGBD. Faremos isso na 


próxima fase: o projeto lógico. 


PROJETO LÓGICO 


O projeto lógico, também conhecido por modelo de dados de baixo nível, objetiva 
transformar o modelo conceitual em um modelo lógico, que depende do tipo de SGBD 
escolhido. Existem diversos modelos lógicos, por exemplo: Rede, hierárquico, relacional, 
orientado a objeto, grafos, chave-valor e XML. No entanto, atualmente, o mais popular é o 
relacional. Como exemplos de SGBD que fazem uso do modelo relacional, podemos citar: 


Oracle, MySQL, PostgreSQL, SQlite e Sql Server. 


t1 ATENÇÃO 


É importante acompanharmos as tendências de mercado sobre o uso de tecnologias de banco 
de dados. No Explore +, no fim do tema, há indicação para pesquisar sobre o portal que tem 


um ranking com atualização mensal sobre o uso de SGBDs. Confira. 


O modelo relacional de banco de dados surgiu na década de 1970 e representa os dados em 
estruturas chamadas tabelas. Cada tabela possui um nome e coluna(s) que compõe(m) a sua 
estrutura. Nossa tarefa é converter o modelo conceitual para o lógico relacional. Para isso, 


utilizaremos regras bem definidas, que dependem dos elementos do DER. 


No dia a dia, a conversão DER para o modelo lógico relacional é realizada com o auxílio de 
alguma ferramenta de modelagem. No entanto, todo profissional de tecnologia da informação 
precisa conhecer os princípios utilizados nessa conversão. A Figura 3 exibe as tabelas 


originadas das entidades do DER do nosso exemplo, construído na etapa de projeto conceitual. 


CLIENTE 


f idcliente INSCRICAO CURSO 


nome T idcurso 
f idcurso 
datanascimento f idoliente 
(0,1) (0,n) (0,n) (0,1) nome 
cpt SA ITI TI A datainscricao RA q 1 
cargahoraria 


email datacancelamento 


telefone e e 


> 


descricao 


>— 


Fonte: Elaboração do autor 


( Figura 3 — Tabelas originadas do DER da Escola. 


No modelo relacional, as entidades de um DER são representadas sob o formato de tabelas, 
por isso, no exemplo, aparecem as tabelas CLIENTE e CURSO. Em especial, a mesma 
decisão foi tomada para representar o relacionamento INSCRICAO. Perceba que nesse ponto 
do projeto ainda não definiremos as características dos atributos, tais como tipos de dados e 


tamanho. Basta apenas que eles estejam vinculados às suas tabelas. 


Além da representação visual do projeto lógico, as tabelas podem ser expressas com o uso de 


representação textual. 
EXEMPLO 


A descrição a seguir corresponde às tabelas originadas das entidades do DER: 


CLIENTE (idcliente, nome, datanascimento, CPF, email, telefone) 


CURSO (idcurso, nome, cargahoraria, descricao) 


INSCRICAO (idcurso,idcliente, datainscricao, datacancelamento) 
Observe que, com base na representação textual, podemos dizer que: 


Um cliente é caracterizado por um identificador, além de possuir as propriedades nome, 


data de nascimento, CPF, e-mail e telefone. 


Um curso possui um identificador, além das propriedades nome, carga horária e 


descrição. 


Uma inscrição associa um cliente a determinado curso, além de possuir as propriedades data 


de inscrição e data de cancelamento. 


Estamos finalizando a nossa jornada nas fases de um projeto de banco de dados. É chegada a 


hora de construir o projeto físico. 


PROJETO FÍSICO 


Durante o projeto físico, definimos os detalhes de implementação dos objetos do banco de 
dados. No caso das tabelas, escolhemos os tipos de dados e tamanho das colunas, e 


especificamos se elas são opcionais ou obrigatórias. 


Os relacionamentos são definidos por uma restrição especial em alguma(s) coluna(s) da tabela 
em questão. Esse tipo de restrição é denominado chave estrangeira. Em geral, o projeto físico 
é realizado com o auxílio de alguma ferramenta gráfica de modelagem. Há inclusive 
ferramentas que funcionam online, muitas vezes com a política de oferecer acesso limitado a 


diversos recursos. 


0 DICA 


Para o nosso exemplo, escolhemos a ferramenta online denominada Vertabelo por ser 


bastante funcional e sem custos para fins educacionais. 


Ao iniciar o design do modelo, escolhemos o SGBD PostgreSQL como produto-alvo da 


modelagem. A Figura 4 representa o modelo físico enriquecido com detalhes de 


implementação compatíveis com o SGBD escolhido. 


CLIENTE INSCRICAO 


idcliente nto PK idcurso int PKFK idcurso int PK 
nome char(90) idcliente int PKFKB nome char(90) 


4 


datanascimento date Y datainscricao date cargahoraria 


cpf char(12) datacancelamento date N descricao 
email char(50) 
telefone char(12) N 


Fonte: Elaboração do autor 


(8 Figura 4 — Modelo físico do estudo de caso Escola. 


Observe que, diferentemente do modelo lógico, cada coluna de tabela no modelo está 
especificada com detalhes relativos ao tipo de dados, além de restrições em algumas colunas 


indicadas pelos marcadores FK, PK e N. 


Na criação do esquema do banco de dados, nós utilizamos uma linguagem declarativa, 
denominada linguagem de consulta estruturada SQL. A parte da SQL que fornece essas 
funcionalidades é denominada Linguagem de Definição de Dados. A Figura 5 apresenta um 


script DDL SQL compatível com o modelo escola. 


«CREATE TABLE CLIENTE ( 
idcliente int NOT NULL, 
nome char (90) NOT NULL, 
4 datanascimento date NOT NULL, 
CPF char(12) NOT NULL, 
email char (50) NOT NULL, 
telefone char(12) NULL, 
PRIMARY KEY (idcliente) ); 
«CREATE TABLE CURSO ( 
10 idcurso int NOT NULL, 
1 nome char (20) NOT NULL, 
cargahoraria int NOT NULL, 
13 descricao char(120) NOT NULL, 
A PRIMARY KEY (idcurso) ); 
CREATE TABLE INSCRICAO ( 
16 | idcurso int NOT NULL, 
NA | idcliente int NOT NULL, 
18 datainscricao date NOT NULL, 
LIS) datacancelamento date NULL, 
2.0 PRIMARY KEY (idcurso, idcliente), 
21 | FOREIGN KEY (idcliente) REFERENCES CLIENTE (idcliente), 
no A FOREIGN KEY (idcurso) REFERENCES CURSO (idcurso) ); 


Fonte: Elaboração do autor 


(O Figura 5 — Script DDL SQL compatível com o estudo de caso Escola. 


Um script SQL DDL é um conjunto de comandos que, no contexto do nosso exemplo, servirão 


para criar as tabelas do banco de dados escola. 


Vamos entender o propósito desse código? 


Observe que: 


A declaração de cada tabela inicia com o comando CREATE TABLE «nometabela>>, 


conforme linhas 1,9 e 15; 


Todo cliente possui um identificador único (idcliente especificado na linha 8); 


Todo curso possui um identificador único (idcurso especificado na linha 14); 


Cada inscrição possui um identificador único, nesse caso composto por um par de 


colunas (idcurso, idcliente especificado na linha 20); 


As linhas 21 e 22 garantem que a inscrição será processada envolvendo 


necessariamente um cliente e um curso previamente existentes no banco de dados. 


Assista, agora, a um vídeo que resume as fases de um projeto de banco de dados estudadas 


nesse módulo. 


Para assistir a um vídeo 
sobre o assunto, acesse a 
versão online deste conteúdo. 


=) 


Ao longo deste módulo, estudamos as fases de um projeto de banco de dados. Percebemos 


Resumindo 


que esta é uma atividade que envolve as seguintes tarefas: 
Levantar requisitos de dados 

Construir um modelo de entidade e relacionamento 
Construir um modelo lógico 

Implementar o modelo físico 


As tarefas de um projeto de banco de dados não são estáticas, visto que os requisitos de 
dados podem evoluir, por exemplo, a partir da necessidade de adaptar o negócio a algum tipo 


de legislação, ou mesmo para tornar o trabalho do usuário mais eficiente. 


VERIFICANDO O APRENDIZADO 


1. O PROJETO DE BANCO DE DADOS É DIVIDIDO EM VÁRIAS ETAPAS. 
UMA DELAS ENVOLVE A CONSTRUÇÃO DE UM MODELO QUE 
DESCREVE A ESTRUTURA DO BANCO DE DADOS, COM SEUS 
OBJETOS, ATRIBUTOS E RELACIONAMENTOS INERENTES AO 
FUNCIONAMENTO DO NEGÓCIO ALVO DA MODELAGEM, 
INDEPENDENTEMENTE DE LIMITAÇÕES TECNOLÓGICAS, 
IMPLEMENTAÇÃO OU ATÉ MESMO DISPOSITIVOS DE 
ARMAZENAMENTO. ESSE MODELO É DENOMINADO: 


A) Conceitual 
B) Lógico 
C) Físico 


D) Prescritivo 


2. ASSINALE A AFIRMATIVA CORRETA ACERCA DAS ETAPAS DE UM 
PROJETO DE BANCO DE DADOS: 


A) Projeto conceitual: É construído um modelo de dados em função de características técnicas 


de implementação existentes em algum SGBD, por exemplo, SQL Server. 


B) Projeto lógico: São especificados esquemas lógicos. Além disso, essa etapa é responsável 
por criar um modelo físico de dados a partir do modelo conceitual independente do SGBD 


escolhido. 


C) Projeto físico: Descreve detalhes sobre tipos de dados e tamanho de colunas. É dependente 


da escolha de um SGBD. 


D) Projeto físico: Possui total independência de um SGBD específico. 


GABARITO 


1. O projeto de banco de dados é dividido em várias etapas. Uma delas envolve a 
construção de um modelo que descreve a estrutura do banco de dados, com seus 
objetos, atributos e relacionamentos inerentes ao funcionamento do negócio alvo da 
modelagem, independentemente de limitações tecnológicas, implementação ou até 


mesmo dispositivos de armazenamento. Esse modelo é denominado: 


A alternativa "A " está correta. 


O modelo conceitual, construído na etapa de projeto conceitual, tem foco na criação de uma 
visão abstrata do banco de dados, facilitando o entendimento do modelo por parte do usuário 
final. Essa visão oculta detalhes de implementação, por exemplo, a respeito de como os dados 


serão armazenados. 


2. Assinale a afirmativa correta acerca das etapas de um projeto de banco de dados: 


A alternativa "C " está correta. 


Na etapa de projeto físico, a partir da escolha de um SGBD, são definidos detalhes de mais 
baixo nível, dependentes das funcionalidades ofertadas pelo SGBD escolhido, visto que o 


resultado dessa etapa corresponde ao banco de dados físico. 


MÓDULO 2 


(O Reconhecer os elementos do diagrama de entidade e relacionamento 


ENTIDADE 


De acordo com Heuser (2009), a entidade corresponde a uma representação do conjunto de 
objetos da realidade modelada sobre os quais se deseja manter informações no banco 
de dados. Em um DER, a entidade é representada por um retângulo e dentro dele definimos o 


nome da entidade. Vamos observar um exemplo na Figura 6. 


ALUNO 


Fonte: Elaboração do autor. 
(3 Figura 6 — Exemplo de representação gráfica de entidade. Nesse caso, o retângulo 
representa o conjunto de todos os alunos sobre os quais há interesse em manter informações 


no banco de dados. 


RELACIONAMENTO 


Heuser (2009) afirma que a propriedade de entidade que especifica as associações entre 
objetos é o relacionamento, o qual corresponde a um conjunto de associações entre 
ocorrências de entidades. Em um DER, representamos o relacionamento por meio de um 
losango ligado por linhas conectadas às entidades envolvidas. Vamos observar um exemplo na 


Figura 7. 


DISCIPLINA 


Fonte: Elaboração do autor. 
& Figura 7 — Exemplo de representação gráfica de relacionamento. Nesse caso, há duas 
entidades, além do relacionamento POSSUI. Todo relacionamento pressupõe a existência dos 


objetos das entidades participantes. 


AUTORRELACIONAMENTO 


Há casos em que um relacionamento envolve ocorrências de uma mesma entidade 
(autorrelacionamento). Em especial, é importante diferenciar o papel que cada ocorrência da 


entidade cumpre no contexto do relacionamento em questão. 


EXEMPLO 


Suponha que, para cursar a disciplina Cálculo Il, seja necessário ter conhecimentos em Cálculo 
|. Esse tipo de situação é conhecido por pré-requisito. A Figura 8 apresenta um 


autorrelacionamento envolvendo pré-requisitos a partir da entidade DISCIPLINA: 


Fonte: Elaboração do autor. 


(3 Figura 8 —- Exemplo de representação gráfica de autorrelacionamento. 


Podemos verificar que o modelo contempla: 


Um conjunto de objetos classificados como disciplinas (entidade DISCIPLINA). 


Um conjunto de associações. Cada associação (relacionamento PREREQUISITO) 
relaciona uma disciplina liberadora (que o aluno precisa ter cumprido) e uma disciplina 


liberada (que o aluno poderá cursar). 


Em nosso exemplo, Cálculo Il é a disciplina liberada e Cálculo |, a liberadora. 


CARDINALIDADE DE RELACIONAMENTOS 


Até o momento, identificamos um relacionamento (POSSUI) entre as entidades CURSO e 


DISCIPLINA. No entanto, surgiram quatro importantes perguntas: 

1. Toda disciplina, para existir no banco de dados, tem de estar associada a algum curso? 
2. Uma disciplina pode estar associada a, no máximo, quantos cursos? 

3. Todo curso, para existir no banco de dados, tem que estar associado a alguma disciplina? 
4. Um curso pode estar associado a, no máximo, quantas disciplinas? 


Expressaremos essas respostas no DER, usando o conceito de cardinalidade em 
relacionamentos. A cardinalidade é um par ordenado sob a forma (mínima, máxima): O ou 1 
para a mínima e 1 ou N para a máxima, com N representando valores maiores que a unidade. 


Vejamos um exemplo na Figura 8. 


Este par (0,N) expressa > 
a participação da entidade 
DISCIPLINA no 
relacionamento POSSUI 


DISCIPLINA 


Este par (0,N) expressa » 
a participação da entidade 


CURSO no relacionamento 
POSSUI 


Fonte: Elaboração do autor. 


(3 Figura 8 — Exemplo de representação gráfica do relacionamento POSSUI, com as 


cardinalidades definidas. 


Podemos então responder: 


PERGUNTA 1 
PERGUNTA 2 
PERGUNTA 3 
PERGUNTA 4 


Não (cardinalidade mínima 0 expressa ao lado da entidade CURSO); 
Vários (cardinalidade máxima n expressa ao lado da entidade CURSO); 
Não (cardinalidade mínima 0 expressa ao lado da entidade DISCIPLINA); 


Várias (cardinalidade máxima n expressa ao lado da entidade DISCIPLINA). 


€1 ATENÇÃO 


Cardinalidade de relacionamento 


Por convenção, cada par ordenado da cardinalidade diz respeito à participação da entidade 


localizada no lado oposto do relacionamento em questão. 


RELACIONAMENTO TERNÁRIO 


Vamos modelar orientações de alunos em projetos, realizadas por docentes. Há três tipos de 
informações: projeto, aluno e docente. Estamos, portanto, diante de um relacionamento 


ternário. A Figura 9 apresenta a parte do DER contemplando esse requisito de dados. 


PROJETO ORIENTACAO DOCENTE 


(0,n) 


Fonte: Elaboração do autor. 


(3 Figura 9 — Exemplo de relacionamento ternário. 


Cada ocorrência do relacionamento ORIENTACAO vincula três ocorrências de entidade: um 
projeto, um aluno a ser orientado e um docente orientador. Em um relacionamento ternário, 
especificamos cada par de cardinalidade com base na relação existente entre o par de 


cardinalidade restante. Veja a seguir o que expressa cada par de cardinalidade: 


CARDINALIDADE MÁXIMA 1 


Expressa no modelo ao lado da entidade DOCENTE, diz respeito ao par (ALUNO, PROJETO). 


Um aluno participante de um projeto pode ser orientado por no máximo um docente. 


CARDINALIDADE MÁXIMA N 


Expressa no modelo ao lado da entidade ALUNO, diz respeito ao par (DOCENTE, PROJETO). 


Um docente participante de um projeto pode orientar diversos alunos. 


CARDINALIDADE MÁXIMA N 


Expressa no modelo ao lado da entidade PROJETO, diz respeito ao par (ALUNO, DOCENTE). 


Um aluno e um docente podem participar de vários projetos. 


ATRIBUTO 


Entidades e relacionamentos podem ter propriedades, que são especificadas pelos atributos. 


[...] ATRIBUTO CORRESPONDE A UM DADO QUE É 
ASSOCIADO A CADA OCORRÊNCIA DE UMA 
ENTIDADE OU DE UM RELACIONAMENTO. 


(HEUSER, 2009) 


Vamos especificar algumas propriedades para as entidades CURSO e DISCIPLINA: 


Todo curso possui um código único, nome e, opcionalmente, data de criação. 


Toda disciplina possui um código único, nome e carga horária. 


A Figura 10 apresenta a parte do DER contemplando esses requisitos de dados: 


CODIGOCURSO 


CODIGODISCIPLINA 


DISCIPLINA (O NOME 


() DATACRIACAO (0, 1) (D CARGAHORARIA 


Fonte: Elaboração do autor. 
& Figura 10 —- DER contemplando atributos das entidades CURSO e DISCIPLINA. 


Percebemos que os atributos CODIGOCURSO e CODIGODISCIPLINA são únicos em suas 


respectivas entidades. Na prática, essa unicidade significa que: 
Todo curso possui valor para o atributo CODIGOCURSO diferente dos demais 
Toda disciplina possui valor para o atributo CODIGODISCIPLINA diferente das demais 


Esse tipo especial de atributo é conhecido por atributo identificador e sua representação gráfica 
é dada por um traço com uma das extremidades contendo um círculo preenchido. De acordo 
com os requisitos de dados, DATADECRIACAO é um atributo opcional, ou seja, não 
obrigatório. Sua representação gráfica é dada por um traço com uma das extremidades 


contendo um círculo pontilhado. Os demais atributos são obrigatórios. 


CARDINALIDADE EM ATRIBUTO 


No DER anterior, ao lado do atributo DATACRIACAO, há um par de cardinalidade com valor 
(0,1). A cardinalidade O expressa que o atributo é opcional. A cardinalidade 1 expressa que o 
atributo é monovalorado. Cada combinação de cardinalidade tem um significado especial, 


conforme Tabela 1: 


Cardinalidade Mínima Cardinalidade Máxima Significado 


0 1 Opcional, Monovalorado 
0 N Opcional, Multivalorado 
1 1 Obrigatório, Monovalorado 
1 N Obrigatório, Multivalorado 


Q 
«O Atenção! Para visualização completa da tabela utilize a rolagem horizontal 


(ty Tabela 1 — Propriedade de atributo de acordo com a cardinalidade. 


ATRIBUTO OBRIGATÓRIO E MONOVALORADO 


Na construção de um DER, a maioria dos atributos é monovalorado e obrigatório. Assim, 
adotaremos a convenção de, nesses casos, não expressar no modelo a cardinalidade 
(1,1) por motivos de legibilidade. Assim, de agora em diante, quando não houver 
cardinalidade expressa em atributos de um DER, considere que eles são monovalorados 


e obrigatórios. 


ATRIBUTO COMPOSTO 


Em modelagem, é comum surgirem atributos mais complexos, que podem ser subdivididos em 
partes menores; eles são conhecidos por atributos compostos. Por exemplo, um atributo 


endereço pode ser subdividido em logradouro, complemento, CEP e cidade. 


MODELO DE ENTIDADE E RELACIONAMENTO 
ESTENDIDO 


O modelo de entidade e relacionamento estendido traz novos componentes semânticos. 


Estudaremos a especialização/generalização, além da entidade associativa. 


ESPECIALIZAÇÃO/GENERALIZAÇÃO 


Imagine que, além dos docentes, seja necessário gerenciar outros funcionários da instituição, 
como os analistas. Podemos deixar previsto que a IES pode ter funcionários que não são 


analistas nem docentes. 


Queremos, ainda, saber a formação de graduação de cada docente. Surge, então, uma 
hierarquia, visto que docente é um subtipo de funcionário. Funcionário é um objeto mais 


genérico, estando, portanto, na posição superior da hierarquia. 


O mecanismo de especialização/generalização é representado por um triângulo, com a 
entidade mais genérica localizada na parte superior e a(s) entidade(s) especializada(s) na parte 


inferior. Vamos observar o DER na Figura 11 com os novos requisitos de dados. 


CODIGOFUNCIONARIO 


(O) NOME 
FUNCIONARIO 
() TELEFONE (1, n) 
DOCENTE ANALISTA 


() GRADUACAO (1, n) 


Fonte: Elaboração do autor. 


(3 Figura 11 —- DER com mecanismo de especialização/generalização. 
Nós podemos perceber que: 
Todo funcionário possui um código único, além de nome e pelo menos um telefone 


Há duas entidades especializadas: DOCENTE e ANALISTA. A entidade DOCENTE possui um 
atributo obrigatório GRADUACAO 


No mecanismo de especialização/generalização há o uso de herança de propriedades: Cada 
entidade especializada herda as propriedades da entidade mais genérica. Assim, todo docente 


herda as propriedades de funcionário. 


CLASSIFICAÇÕES PARA 
ESPECIALIZAÇÃO/GENERALIZAÇÃO 


Observe que perguntas surgem quando analisamos o DER apresentado anteriormente. 
Pode existir funcionário que não seja nem docente nem analista? 
Pode existir funcionário que seja docente e analista”? 


A classificação total/parcial responde ao primeiro questionamento: Se a resposta for não, a 


especialização é total. Caso contrário, parcial. O segundo é respondido com auxílio da 


classificação exclusiva/compartilhada: Se a resposta for não, a especialização é exclusiva. 


Caso contrário, compartilhada. As combinações das classes estão expressas na Tabela 2: 


Exclusiva(x) Compartilhada(c) 


Total(t) tx tc 


Parcial(p) px pc 


Q 
«O Atenção! Para visualização completa da tabela utilize a rolagem horizontal 


f& Tabela 2 — Classificação do mecanismo de especialização/generalização. 


EXEMPLO 


Vamos convencionar respostas às perguntas realizadas: 
1. Pode existir funcionário que não seja nem docente nem analista? Sim. 
2. Pode existir funcionário que seja docente e analista? Sim. 


Agora vamos observar o DER na Figura 12, já com a com informação (pc) sobre a classificação 


do mecanismo de especialização/generalização. 


Fonte: Elaboração do autor. 


(& Figura 12 - DER com mecanismo de especialização/generalização fazendo uso das 


classificações parcial e compartilhada. 


No exemplo, parcial significa que pode existir funcionário não especializado, ou seja, não 
classificado como docente ou analista. Por fim, compartilhado significa que no contexto da 


IES pode existir funcionário que atue como docente e na função de analista. 


ENTIDADE ASSOCIATIVA 


É comum a necessidade de vincular entidade a algum relacionamento. Ao modelarmos a 
inscrição de alunos em disciplinas, criaremos turmas para serem associadas às disciplinas que 


serão liberadas para inscrição. Suponha que: 


Toda turma possui código, descrição e data de criação. Além disso, pode estar associada a 


diversas disciplinas. Uma disciplina pode ser ofertada em várias turmas 


Ao ofertar uma disciplina, é necessário saber o número de vagas e quando o aluno fez 


inscrição na mesma 


Haverá um relacionamento (OFERTA) entre TURMA e DISCIPLINA. OFERTA deverá estar 
associada a ALUNO, via relacionamento INSCRICAO. Como resolver esse impasse? O objeto 
entidade associativa surgiu como alternativa de modelagem em situações dessa natureza. Ela 


é representada por um losango desenhado dentro de um retângulo. 


Observe o modelo na Figura 13: 


CODIGOALUNO 


CODIGODISCIPLINA 
DISCIPLINA 
(O NOME 


(O CARGAHORARIA 


Fonte: Elaboração do autor. 


(8 Figura 13 —- DER com os novos requisitos de dados, fazendo uso de entidade associativa. 


É necessário enxergar OFERTA sob duas perspectivas: 


RELACIONAMENTO 
ENTIDADE 


OFERTA possui atributo VAGAS, útil no planejamento das turmas e disciplinas que serão 


ofertadas para inscrição. 


OFERTA útil para identificar a turma e a disciplina escolhida pelo aluno quando do momento de 


uma inscrição. 


Vamos conhecer um estudo de caso para entender melhor os modelos de entidades e 


relacionamento: 


Para assistir a um vídeo > 
sobre o assunto, acesse a (6) 


versão online deste conteúdo. -=0 


Resumindo 


No segundo módulo, estudamos os componentes de um diagrama de entidade e 
relacionamento (DER). Além disso, conhecemos elementos do modelo de entidade e 


relacionamento estendido. 


VERIFICANDO O APRENDIZADO 


1. CONSIDERE O DER A SEGUIR SOBRE INSCRIÇÃO EM CONCURSO 
PÚBLICO. QUAL PROPOSIÇÃO ESTÁ CORRETA? 


CODIGOCANDIDATO 
O 


CODIGOEXAME 
CANDIDATO 


A) A fim de adicionar ao modelo informações do EXAME para, posteriormente, armazenar 
dados referentes às provas, a alternativa mais indicada é criar um atributo simples na entidade 


CANDIDATO. 


B) O atributo DATA está representado incorretamente no modelo, uma vez que não é permitido 


modelar atributo em relacionamento. 


C) De acordo com o modelo apresentado, um CANDIDATO pode inscrever-se em mais de um 
EXAME. 


D) No modelo, há um relacionamento ternário, pois estão envolvidos três objetos: 


CANDIDATO, INSCRICAO e EXAME. 


2. CONSIDERE O DER A SEGUIR. QUAIS PROPOSIÇÕES ESTÃO 
CORRETAS? 


O NOME O coDicoruncioNaRIO 
CODIGODEPARTAMENTO HO NomE O sexo 


o ” (0,n) (0,1) CODIGOCARGO 
DEPARTAMENTO | (0) (On) | FUNCIONARIO CARGO 
NOME 
SALARIO 


|. TODO FUNCIONÁRIO ESTÁ ALOCADO EM UM DEPARTAMENTO. 


Il. NÃO PODE EXISTIR MAIS DE UM CARGO COM O MESMO SALÁRIO. 


Il. SALARIO É CONSIDERADO UM ATRIBUTO OBRIGATÓRIO EM CARGO. 


IV. CODIGOCARGO É CONSIDERADO UM ATRIBUTO OBRIGATÓRIO NA 


ENTIDADE CARGO. 


V. O ATRIBUTO NOME DA ENTIDADE FUNCIONARIO É DO TIPO 
COMPOSTO. 


A) Ile IV 
B)llleV 
C) |, Ile IV 


D)lell 


GABARITO 


1. Considere o DER a seguir sobre inscrição em concurso público. Qual proposição está 


correta? 


CODIGOCANDIDATO 
Õ 


CODIGOEXAME 
CANDIDATO 


A alternativa "C " está correta. 


A proposição da alternativa C está correta, pois a informação sobre o número de vezes em que 
um CANDIDATO pode fazer inscrição em exames é definido pela cardinalidade máxima n, 


expressa ao lado da entidade EXAME. 


2. Considere o DER a seguir. Quais proposições estão corretas? 


O nomE O cobicoruNcioNaRIo 
CODIGODEPARTAMENTO O NoME O sEXxO 


E - (0,n) (0,1) CODIGOCARGO 
DEPARTAMENTO | (0) (0,n) | FUNCIONARIO CARGO 
NOME 
SALARIO 


I. Todo funcionário está alocado em um departamento. 

Il. Não pode existir mais de um cargo com o mesmo salário. 

Ill. SALARIO é considerado um atributo obrigatório em CARGO. 

IV. CODIGOCARGO é considerado um atributo obrigatório na entidade CARGO. 


V. O atributo nome da entidade FUNCIONARIO é do tipo composto. 


A alternativa "A " está correta. 


A proposição Ill está correta, pois, em nosso estudo, convencionamos que todo atributo sem a 
cardinalidade explícita será considerado obrigatório e monovalorado. A proposição IV está 


correta, pois todo atributo identificador por padrão é obrigatório. 


MÓDULO 3 


(O Compreender a modelagem de entidades e relacionamentos 


OBJETIVOS AO CONSTRUIR UM DER 


Um DER deve capturar as partes mais importantes do negócio sendo modelado, pois pessoas 
diferentes precisam ter o mesmo entendimento do modelo. Manter um DER atualizado facilita a 
vida dos profissionais de TI, já que, com a documentação atualizada, a curva de aprendizado 


sobre a organização pode ser minimizada. 


Apesar de ser relativamente simples construir um DER, é comum identificarmos propriedades 
desejáveis no banco de dados que precisam ser registradas mas não podem ser expressas 


diretamente no modelo. Na linguagem técnica de banco de dados, regras que devem ser 


obedecidas pelo SGBD em relação ao banco de dados são conhecidas por restrições de 


integridade. 


Há restrições de integridade expressas por meio de algum elemento do próprio DER, por 
exemplo, ao definirmos cardinalidade para algum atributo. No entanto, há restrições que 
precisam ser expressas em separado, normalmente usando linguagem natural. Essas, 


normalmente, são conhecidas como restrições semânticas. 


EXEMPLO 


Podemos estabelecer que, no relacionamento de orientação realizado por docentes aos alunos 
no contexto de um projeto, a data de término da orientação nunca deve ser menor que a data 
de início. Estamos diante de uma restrição que leva em conta dois atributos de relacionamento 
definidos no DER. Nós especificamos essa restrição no DER com o uso de linguagem natural 


sob a forma de um texto. Veja na Figura 14 como ficou o modelo: 


Fonte: Elaboração do autor. 


(3 Figura 14 — DER com uma restrição semântica adicionada sob o formato de um texto. 


tt ATENÇÃO 


O quanto devo modificar um DER para registrar restrições de integridade? 


O objetivo fundamental na construção de um DER é projetar um banco de dados e não 


descrever todas as restrições de integridade. 


MODELAGEM DE ENTIDADES E 
RELACIONAMENTOS 


A partir de agora, daremos ênfase no processo de modelagem de entidades e 


relacionamentos. 


No entanto, modelos diferentes podem obter o mesmo resultado prático? 


EQUIVALÊNCIA ENTRE MODELOS 


[...] PARA FINS DE PROJETO DE BANCO DE DADOS, 
DOIS MODELOS ER SÃO EQUIVALENTES QUANDO 
AMBOS GERAM O MESMO ESQUEMA DE BANCO DE 
DADOS. 


(HEUSER, 2009) 


EXEMPLO 


Observe o DER expresso na Figura 15: 


Fonte: Elaboração do autor. 


&& Figura 15 — DER associando disciplinas a cursos, com uso de relacionamento N:N. 


Ao analisarmos o DER, percebemos que a cardinalidade máxima do relacionamento POSSUI é 
do tipo N:N. Sendo assim, um modelo equivalente sem uso de relacionamento N:N será criado, 


onde POSSUI será modelado como entidade, conforme expresso na Figura 16: 


Fonte: Elaboração do autor. 


(3 Figura 16 — DER associando disciplinas a cursos, sem relacionamento N:N. 


Generalizando, todo relacionamento N:N pode ser transformado em entidade. Para isso, basta 


seguir as etapas a seguir. 


ETAPA 01 
ETAPA 02 
ETAPA 03 
ETAPA 04 
ETAPA 05 


Representar o relacionamento N:N como uma entidade. 
Relacionar a entidade criada na etapa 1 às entidades participantes do relacionamento original. 


Adicionar à entidade criada na etapa 1 o(s) atributo(s) — caso exista(m) — do relacionamento 


original. 


A entidade criada na etapa 1 será identificada pelos relacionamentos com as entidades 


participantes do relacionamento original. 


Estabelecer a cardinalidade (1,1) da entidade criada na etapa 1 para cada relacionamento 


vinculado a ela. 


O SAIBA MAIS 


Para complementar o nosso entendimento, a seguir adicionamos observações sobre o nosso 


modelo, de acordo com as etapas apresentadas anteriormente. 


1. Representar o relacionamento N:N como uma entidade: Foi criada a entidade POSSUI. 


2. Relacionar a entidade criada na etapa 1 às entidades participantes do relacionamento 
original: A entidade POSSUI foi relacionada às entidades CURSO e DISCIPLINA. 


3. Adicionar à entidade criada na etapa 1 o(s) atributo(s) — caso exista(m) — do relacionamento 
original: Como não havia atributos no relacionamento original, a entidade POSSUI foi criada 


sem atributos. 


4. A entidade criada na etapa 1 será identificada pelos relacionamentos com as entidades 
participantes do relacionamento original: Esta identificação está representada no modelo com 


as linhas mais espessas saindo da entidade POSSUI. 


5. Estabelecer a cardinalidade (1,1) da entidade criada na etapa 1 para cada relacionamento 


vinculado a ela: As cardinalidades estão representadas ao lado da entidade POSSUI. 


tt ATENÇÃO 


O relacionamento POSSUI só será cadastrado no banco de dados se houver tanto uma 
disciplina quanto um curso. Essa observação é consequência da definição de relacionamento 
em modelagem de dados. Assim, quando transformamos um relacionamento em entidade, 


essa restrição deve ser mantida. De que maneira? 


No DER modificado, as linhas mais espessas saindo da entidade POSSUI representam a 
restrição de que toda ocorrência desta entidade é dependente da existência tanto de uma 
disciplina quanto de um curso. Alguns autores chamam entidade fraca a uma entidade que 


depende de outra(s) para existir. 


MODELAGEM DE ENTIDADE ISOLADA 


O DER que nós estamos modelando é referente ao funcionamento de uma única IES. Em 
função disso, não há necessidade de informar no banco de dados em qual instituição o aluno 


está cadastrado ou mesmo à qual IES os cursos estão relacionados. 


[...] UMA ENTIDADE ISOLADA É UMA ENTIDADE QUE 
NÃO APRESENTA RELACIONAMENTO COM OUTRAS 
ENTIDADES. 


HEUSER, 2009. 


No contexto do nosso DER, uma entidade isolada pode servir para modelar características da 
IES, tais como código e CNPJ. Portanto, se decidirmos adicionar uma entidade INSTITUICAO 
ao nosso modelo, esta deverá permanecer isolada, dado que, de acordo com os requisitos de 
dados, o banco de dados refere-se a uma única IES. A Figura 17 representa a entidade isolada 


INSTITUICAO e seus atributos: 


CODIGOIES 
INSTITUICAO 
() CNPJ 


Fonte: Elaboração do autor. 


É Figura 17 — DER com entidade isolada IES. 


Observe que com a entidade INSTITUICAO criada, caso haja necessidade de acrescentar 
outras características simples à IES, basta adicionar atributos. Por exemplo, poderíamos 


adicionar informações sobre data de criação, nome da IES, telefone, entre outras. 


QUANDO MANTER HISTÓRICO 


Em nosso modelo acadêmico, vamos considerar que surgiu a necessidade de associar docente 
a departamento. Essa é uma necessidade comum em praticamente toda IES: Saber quais 


professores pertencem a qual departamento. 


Vamos supor que, após o surgimento dessa demanda, nós levantamos os seguintes requisitos 


de dados: 


Todo departamento é identificado por um código e possui um nome. 


Um docente pode estar associado a, no máximo, um departamento. 


Com base nos requisitos, construímos o DER mostrado na Figura 18. 


CODIGOFUNCIONARIO 


(O NOME 
FUNCIONARIO 
(O TELEFONE (1, n) 
ANALISTA | 


(O GRADUACAO (1, n) 


DOCENTE 


DEPARTAMENTO 


CODIGODEPARTAMENTO 


Fonte: Elaboração do autor. 


(3 Figura 18 — DER associando docente a departamento. 


Nós podemos perceber que o DER construído está de acordo com os novos requisitos de 


dados, pois: 


As informações dos departamentos estão expressas na entidade DEPARTAMENTO. 


A restrição de que um docente está associado a, no máximo, 1 departamento está 


expressa na cardinalidade máxima 1 ao lado da entidade DEPARTAMENTO. 


Ora, os requisitos de dados associados a um projeto de banco de dados podem sofrer 
alterações ao longo do tempo. Assim, é necessário planejarmos uma estratégia para refletir as 
restrições impostas pelo novo cenário. Vamos supor, então, o surgimento de novo requisito de 


dados: 


É necessário armazenar no banco de dados a movimentação de docentes entre 


departamentos. 


A atuação do docente em um departamento possui uma data de início e uma data de fim. 


Esse novo requisito de dados pode ser interpretado como uma necessidade institucional de 
manter histórico das movimentações de docentes entre departamentos. O DER contemplando 


o novo requisito está expresso na figura a seguir: 


CODIGOFUNCIONARIO 


(O NOME 
FUNCIONARIO 
(O TELEFONE (1, n) 
ANALISTA | 


(O GRADUACAO (1, n) 


(O NOME (O DATAFIM(0,1) 


DEPARTAMENTO 


CODIGODEPARTAMENTO 


DOCENTE 


(O DATAINICIO 


Fonte: Elaboração do autor. 
(8 Figura 19 — DER associando docente a departamento, contendo histórico das 


movimentações. 


Podemos perceber que, no novo DER: 


A cardinalidade máxima N expressa ao lado da entidade DEPARTAMENTO indica que ao 
longo do seu ciclo profissional um docente pode ter passado por diversos departamentos 


da IES. 


A atuação do docente em um departamento é caracterizada por uma data de início e uma 


data de fim. 


Perceba que o DER contemplando o novo requisito de dados é semelhante ao DER original. A 
diferença foi a alteração de uma cardinalidade máxima, além da adição de dois atributos no 


relacionamento. 


MAIS SOBRE MODELAGEM DE ENTIDADES 
E RELACIONAMENTOS 


Você deve ter notado que um DER não é construído em uma única etapa. Em projetos de 
banco de dados reais, a construção de um DER é um processo incremental, ou seja, o modelo 
vai sendo modificado e enriquecido de forma gradativa à medida que novos requisitos de 


dados sejam levantados. 


Ao longo dos exemplos que construímos, nós utilizamos uma estratégia que envolveu a 


modelagem de conceitos mais abstratos que em seguida foram sendo detalhados. Em geral, 


identificamos algumas entidades e depois definimos seus atributos e relacionamentos. Esta 
estratégia de modelagem que escolhemos é conhecida por estratégia descendente. O passo a 
passo a seguir resume etapas utilizadas ao adotarmos esse tipo de estratégia para construção 


do diagrama de entidade e relacionamento. 


1. MODELO INICIAL 


Identificar entidades 
Identificar relacionamentos, especializações e cardinalidade máxima de relacionamentos 
Mapear atributos de entidades e relacionamentos 


Mapear identificadores de entidades e relacionamentos 


2. MODELO DETALHADO 


Definir as cardinalidades dos relacionamentos 


Identificar outras restrições de integridade 


3. VALIDAÇÃO 


Revisar o modelo 


Validar o modelo junto ao usuário 


É importante observarmos que em qualquer etapa é possível retornar à etapa anterior, dado 


que estamos diante de uma construção que envolve um DER que ocorre de forma gradativa. 


Vamos conhecer mais sobre o raciocínio para a construção da modelagem de entidades e 


relacionamentos: 


Para assistir a um vídeo > 
sobre o assunto, acesse a 6) 


versão online deste conteúdo. -=0 


Resumindo 


Ao longo deste módulo, estudamos a construção de um DER com ênfase na modelagem de 
entidades e relacionamentos. Percebemos que modelos diferentes podem ser gerados a partir 
dos mesmos requisitos de dados. Outro importante item que exploramos diz respeito a 
modificações em um DER com objetivo de registrar histórico de informações. Aprendemos, 
ainda, que a construção de um DER é um processo sistemático e incremental, em que é 


possível refinar o modelo em cada etapa. 


VERIFICANDO O APRENDIZADO 


1. UMA CAFETERIA QUE COMERCIALIZA PRODUTOS ALIMENTÍCIOS 
REALIZA COMPRAS DIÁRIAS DE UMA COOPERATIVA E ESTÁ 
ENFRENTANDO DIFICULDADES POR CAUSA DE GESTÃO DO PRAZO DE 
VALIDADE DE SEUS PRODUTOS. 

O PROPRIETÁRIO VAI INVESTIR EM UM SISTEMA QUE REALIZARÁ O 
CONTROLE DO ESTOQUE E DO PRAZO DE VALIDADE TOMANDO COMO 
BASE A DATA DE COMPRA DE CADA PRODUTO ADQUIRIDO DA 
COOPERATIVA. O DER PARCIAL A SEGUIR REPRESENTA A 
MODELAGEM DE DADOS PROPOSTA POR UM PROFISSIONAL, SENDO 
QUE O ATRIBUTO CÓDIGO EM CADA ENTIDADE É ÚNICO. 


(O DESCRICAO HO VALIDADE (O cnPJ 


PRODUTO (D NOME 
COOPERATIVA 


CODIGOP |) TIPODEPRODUTO CODIGOCL(O TELEFONE (1, n) 


(O DATACOMPRA 


LO QUANTIDADE 


A PARTIR DAS INFORMAÇÕES, É CORRETO AFIRMAR QUE: 


A) O relacionamento entre as entidades PRODUTO e COOPERATIVA é do tipo um-para- 


muitos. 
B) O atributo telefone da entidade COOPERATIVA é do tipo composto. 
C) O atributo CODIGOP da entidade PRODUTO é classificado como opcional. 


D) É possível construir um novo DER modelando estoque como entidade, sem perda de 


informação em relação ao modelo original. 


2. UMA REDE DE OPERADORAS DE PLANOS DE SAÚDE NECESSITA DE 
UM SISTEMA PARA CONTROLAR SEUS CONTRATOS JUNTO À REDE 
CREDENCIADA DE HOSPITAIS. CADA CONTRATO ENTRE A OPERADORA 
E UM HOSPITAL TEM DURAÇÃO DE DOIS ANOS. APÓS O TÉRMINO 


DESSE PRAZO, UM NOVO PODERÁ SER EMITIDO, CASO HAJA 
INTERESSE ENTRE AS PARTES. QUAL ALTERNATIVA A SEGUIR 
REPRESENTA UM DER ADEQUADO AOS REQUISITOS DE DADOS 
APRESENTADOS? 


A) 


() DATAINICIO 


() DATANNICIO 


CODIGOH 


D) 


DATAINÍCIO 


CONTRATO 


HOSPITAL CODIGOH 


D) 


GABARITO 


1. Uma cafeteria que comercializa produtos alimentícios realiza compras diárias de uma 
cooperativa e está enfrentando dificuldades por causa de gestão do prazo de validade de 
seus produtos. 

O proprietário vai investir em um sistema que realizará o controle do estoque e do prazo 
de validade tomando como base a data de compra de cada produto adquirido da 
cooperativa. O DER parcial a seguir representa a modelagem de dados proposta por um 


profissional, sendo que o atributo código em cada entidade é único. 


(O DESCRICAO HO VALIDADE (O CNPJ 


PRODUTO (O NOME 
COOPERATIVA 


CODIGOP -() TIPODEPRODUTO CODIGOCL(O) TELEFONE (1, n) 


(O DATACOMPRA 


(O) QUANTIDADE 


A partir das informações, é correto afirmar que: 


A alternativa "D " está correta. 


De fato, quando o DER tem relacionamento N:N, é possível construir um modelo equivalente, 
em que o relacionamento em questão será substituído por uma entidade, mantendo a 


semântica do modelo original. 


2. Uma rede de operadoras de planos de saúde necessita de um sistema para controlar 


seus contratos junto à rede credenciada de hospitais. Cada contrato entre a operadora e 


um hospital tem duração de dois anos. Após o término desse prazo, um novo poderá ser 
emitido, caso haja interesse entre as partes. Qual alternativa a seguir representa um DER 


adequado aos requisitos de dados apresentados? 


A alternativa "B " está correta. 


De fato, de acordo com os requisitos de dados, uma operadora pode realizar diversos contratos 
com o mesmo hospital e vice-versa. Isso implica que a cardinalidade máxima do 
relacionamento CONTRATO seja do tipo N:N. Além disso, os atributos DATAINICIO e DATAFIM 
são propriedades associadas ao relacionamento CONTRATO, permitindo recuperar 


informações históricas. 


MÓDULO 4 


(O Compreender a modelagem de atributos 


ATRIBUTO X ENTIDADE 


Em todos os exemplos que desenvolvemos até o momento, caracterizamos entidades e 
relacionamentos com o auxílio da especificação de atributos. No entanto, em algumas 


situações, modelar um objeto como atributo pode não ser a melhor alternativa. 


No contexto do nosso exemplo acadêmico, é necessário que todo docente tenha pelo menos 
uma graduação registrada no banco de dados. Esse requisito está expresso no modelo a 


seguir. 


CODIGOFUNCIONARIO 


(O NOME 


FUNCIONARIO : 
“ ) TELEFONE (0, n) 


DOCENTE ANALISTA 


() GRADUACAO (1, n) 


Fonte: Elaboração do autor. 


& Figura 20 — DER com informação sobre o docente [graduação mapeada como atributo]. 
Precisamos lembrar que a graduação do docente está expressa sob o formato de atributo. 


A cardinalidade mínima 1 significa que a informação é obrigatória. 


A cardinalidade máxima N representa a informação de que é possível registrar no banco de 


dados diversos cursos associados ao docente. 


EXEMPLO 


Se diversos docentes são formados em Ciência da Computação, não faz muito sentido entrar 
com essa informação no sistema diversas vezes. Mesmo porque, em se tratando de 
informação textual, daria possibilidade de mais de uma forma de representação para o mesmo 


item. 


Caso, além da informação referente ao nome da graduação, quiséssemos saber o ano em que 
o docente se formou, estaríamos diante de uma situação em que o mais adequado seria 
modelar o objeto graduação como uma entidade. Assim, diante do novo cenário, o modelo 


modificado está representado na Figura 21. 


Fonte: Elaboração do autor. 


O Figura 21 — DER com informação sobre o docente [graduação mapeada como entidade]. 


Vamos perceber que no novo DER: 


O objeto graduação foi mapeado sob o formato de entidade. 


É possível cadastrar graduações sem vínculo algum a qualquer docente. Essa conclusão 


ocorre em função da cardinalidade mínima O expressa ao lado da entidade DOCENTE. 


Todo docente necessariamente possui uma graduação. Essa conclusão ocorre em função 


da cardinalidade mínima 1 expressa ao lado da entidade GRADUACAO. 


Finalmente, se estivéssemos interessados em modelar um atributo ANOFIM com objetivo de 
saber o ano de término da graduação pelo docente, bastaria adicionarmos esse atributo ao 


relacionamento DOCENTEGRAD. 


ATRIBUTO X ESPECIALIZAÇÃO 


Uma situação comum durante a construção de um DER é decidir entre modelar um objeto sob 
o formato de atributo ou especialização. O critério a ser usado na decisão é simples: Caso o 


objeto em questão possua atributo(s) ou mesmo relacionamento(s), usa-se a especialização. 


No DER apresentado, a entidade FUNCIONARIO foi especializada. Devemos perceber que a 
entidade DOCENTE está relacionada com a entidade GRADUACAO. Portanto, houve escolha 


coerente com o critério apresentado. 


ATRIBUTO OPCIONAL 


Há situações em que surgem diversos atributos opcionais em uma entidade. Devemos, 
portanto, estar atentos para perceber se os atributos em questão indicam prováveis entidades 


especializadas. 


EXEMPLO 


Suponha que, a partir de agora, tenhamos que saber se determinado funcionário tem registro 
na Ordem dos Advogados do Brasil (OAB) ou na Associação Brasileira de Odontologia (ABO). 


Assim, diante do novo cenário, o modelo modificado está representado na Figura 22. 


Fonte: Elaboração do autor. 


(3 Figura 22 — DER com informação sobre OAB e ABO. 


No DER, foram adicionados os atributos OAB e ABO à entidade FUNCIONARIO. Devemos 
perceber que ambos são opcionais, no entanto, não sabemos quais combinações de atributos 


são válidas. Por exemplo, um funcionário pode ter atributos ABO e OAB? 


Se realizarmos uma análise mais criteriosa no modelo, vamos perceber que os atributos ABO e 
OAB parecem ocultar diferentes categorias: Advogados e odontólogos. Sendo assim, vamos 
modificar o modelo optando por modelar os atributos ABO e OAB como entidades 


especializadas de FUNCIONARIO. Logo, o modelo a seguir representa as mudanças. 


Fonte: Elaboração do autor. 


(O Figura 23 — DER com informação sobre OAB e ABO modeladas com uso do mecanismo de 


especialização. 


Finalmente, devemos perceber que a estratégia adotada tem a vantagem de modelar a 
realidade com mais fidelidade, ao mesmo tempo que evitou modelagem de atributos opcionais 


na entidade FUNCIONARIO. 


ATRIBUTO MULTIVALORADO 


Em nosso DER, vamos supor que, a partir de agora, seja necessário modelar que um 
funcionário pode ter dependente(s). Ora, vamos perceber que uma primeira linha de raciocínio 
para realizar a modelagem desse novo requisito de dados é adicionar um atributo opcional na 


entidade FUNCIONARIO, conforme expresso na Figura 24. 


CODIGOFUNCIONARIO 


DEPENDENTE (0, n)í..) ( ) NOME 


FUNCIONARIO 


(O) TELEFONE (0, n) 


Fonte: Elaboração do autor. 
(O Figura 24 — DER com informação sobre dependente(s) modelada sob a forma de atributo 


multivalorado. 
Há dois motivos para evitarmos esse tipo de modelagem: 


Ao construirmos o modelo físico, vamos perceber que não existe uma implementação direta 


para atributos multivalorados em um SGBD relacional 
Na maioria dos casos, atributos multivalorados escondem atributos e relacionamentos 


É desejável que o banco de dados possa controlar, por exemplo, o nome e a data de 
nascimento de cada dependente. De forma semelhante, seria igualmente desejável diferenciar 


o tipo ou a categoria de cada telefone pertencente ao funcionário. 


EXEMPLO 


O DER a seguir apresenta tanto a modelagem de dependentes quanto a de telefone sob a 


perspectiva de entidades relacionadas à entidade FUNCIONARIO: 


Fonte: Elaboração do autor. 


& Figura 25 — DER com informações sobre dependente(s) e telefone(s) modeladas sob o 


formato de entidade. 


Podemos observar que, após a decisão de modelar os objetos dependente e telefone como 
entidades relacionadas à entidade FUNCIONARIO, além de termos eliminado atributos 
opcionais, conseguimos deixar o modelo mais preciso, legível e com a possibilidade de 


adicionar novos atributos para as entidades de maneira mais natural. 


ATRIBUTO X REDUNDÂNCIA 


Estamos chegando ao final do nosso módulo e do tema referente ao assunto de modelagem 
conceitual. No entanto, é necessário observar a uma situação muito comum em modelagem de 


dados: atributos redundantes. 


ATRIBUTOS REDUNDANTES 


Atributos redundantes são atributos deriváveis a partir da execução de procedimentos de 


busca de dados e/ou cálculos sobre o banco de dados (HEUSER, 2009). 


EXEMPLO 


Em nosso exemplo acadêmico, vamos supor que seja necessário sabermos a quantidade de 
dependentes de cada funcionário. Além disso, precisamos identificar, para cada dependente, o 


número de matrícula do funcionário responsável. 


O uso de atributos redundantes está expresso na figura a seguir, propositalmente em destaque: 


Fonte: Elaboração do autor. 


( Figura 26 — DER com atributos redundantes. 


Devemos perceber que: 


Não é necessário manter o atributo QTDEDEPENDENTES na entidade FUNCIONARIO, 
pois a informação sobre a quantidade de funcionários pode ser obtida a partir de um 


simples processo de cálculo envolvendo o relacionamento. 


Não é necessário manter o atributo CODIGOFUNCIONARIO na entidade DEPENDENTE, 
pois seu valor pode ser obtido ao acessar a entidade FUNCIONARIO através do 


relacionamento. 


Finalmente, atributos redundantes devem ser omitidos do DER, uma vez que esse tipo de 


modelo não diferencia atributos redundantes dos sem redundância. 


ATRIBUTO COMPOSTO 


O atributo composto pode ser dividido em subpartes ou atributos básicos com significados 


próprios. 
EXEMPLO 


Em nosso DER, para fins ilustrativos, nós inicialmente modelamos o endereço do aluno através 
de um atributo composto subdividido em logradouro e complemento. Se adicionarmos mais 
alguns atributos básicos representativos de outras partes de um endereço, teremos um DER 


como a seguir. 


Fonte: Elaboração do autor. 


(Q Figura 27 — DER representando a entidade ALUNO com atributo composto endereço. 


Como desvantagem, o modelo ficou com um visual bastante denso. Por outro lado, é comum 
modelarmos o objeto alvo do atributo composto sob o formato de entidade relacionada à 


entidade principal. Vamos então observar essa mudança na figura a seguir: 


Fonte: Elaboração do autor. 


(8 Figura 28 — DER representando endereço como entidade. 


Perceba que, após eliminarmos o atributo composto, o modelo ficou menos poluído 


visualmente, tornando-se mais legível. 


Vamos conhecer agora alguns aspectos mais avançados da modelagem de atributos: 


Para assistir a um vídeo > 
sobre o assunto, acesse a (6) 


versão online deste conteúdo. -=0 


Resumindo 


Ao longo da nossa jornada neste módulo, demos ênfase ao processo de modelagem de 
atributos. Estudamos diretrizes importantes que devemos levar em consideração ao nos 
depararmos com atributos opcionais, multivalorados ou mesmo compostos. Percebemos, 


ainda, que devemos evitar a modelagem de atributos redundantes. 


VERIFICANDO O APRENDIZADO 


1. O DER A SEGUIR REPRESENTA INFORMAÇÕES SOBRE CLIENTES. 


(O NOME 


CODIGOCLIENTE 


CLIENTE Ls 


NO QUE SE REFERE À MODELAGEM DOS ATRIBUTOS, ASSINALE A 
ALTERNATIVA VERDADEIRA: 


( ) TELEFONE (0, n) 
DTNASCIMENTO () 


A) O atributo CODIGOCLIENTE admite repetição de valores. 


B) O atributo DTNASCIMENTO é opcional e composto. 


C) É mais adequado modelar telefone em uma entidade separada, relacionada à entidade 
CLIENTE. 


D) Todos os atributos são obrigatórios. 


2. O DER A SEGUIR REPRESENTA INFORMAÇÕES SOBRE 
FUNCIONÁRIOS E SEUS DEPENDENTES. 


() NOME 


CODIGOFUNCIONARIO 


FUNCIONARIO 


(1,1) 


DTNASCIMENTO () 


(0,n) 


DEPENDENTE O NOME 
(O DTNASCIMENTO 


() CODIGOFUNCIONARIO 


NO QUE SE REFERE À MODELAGEM DOS ATRIBUTOS, ASSINALE A 
ALTERNATIVA VERDADEIRA: 


A) O atributo CODIGOFUNCIONARIO da entidade DEPENDENTE é redundante. 
B) O atributo CODIGOFUNCIONARIO da entidade FUNCIONARIO é opcional. 
C) Os atributos NOME em ambas as entidades são multivalorados. 


D) Os atributos DTNASCIMENTO em ambas as entidades são multivalorados. 


GABARITO 


1. O DER a seguir representa informações sobre clientes. 


(O NOME 


CODIGOCLIENTE 


+ ) TELEFONE (0, n) 


DTNASCIMENTO (O) CLIENTE 


No que se refere à modelagem dos atributos, assinale a alternativa verdadeira: 


A alternativa "C " está correta. 


Em um SGBD relacional não há implementação direta para atributo multivalorado, como é o 


caso de TELEFONE. Além disso, o modelo fica mais legível quando modelamos TELEFONE 


em entidade própria. 


2. O DER a seguir representa informações sobre funcionários e seus dependentes. 


() NOME 


CODIGOFUNCIONARIO 


FUNCIONARIO 


DTNASCIMENTO (O) 


(O NOME 
(O DTNASCIMENTO 


DEPENDENTE 


() CODIGOFUNCIONARIO 


No que se refere à modelagem dos atributos, assinale a alternativa verdadeira: 


A alternativa "A " está correta. 


De fato, há redundância, visto que é possível localizar o funcionário responsável por cada 


dependente ao acessar a entidade FUNCIONARIO através do relacionamento. 


CONCLUSÃO 


CONSIDERAÇÕES FINAIS 


Este tema apresentou as principais etapas de um projeto de banco de dados, iniciando pelo 
levantamento de requisitos e, em seguida, passando pelos projetos conceitual, lógico e físico. 
Foram examinados os elementos presentes em um DER, bem como o mecanismo de 
especialização/generalização e o de entidade associativa, pertencentes ao modelo de entidade 


e relacionamento estendido. 


Finalmente, praticamos a atividade de modelagem, inicialmente com foco em entidades e 
relacionamentos, terminando com o estudo de exemplos envolvendo a modelagem de 


atributos. 


Para ouvir um podcast sobre 
o assunto, acesse a versão 
online deste conteúdo. 
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EXPLORE+ 


Como vimos, um projeto de banco de dados envolve diversas etapas bem definidas. Além 
disso, a construção de um DER é um processo incremental, sendo possível que o 
diagrama seja revisado e alterado para atender a novos requisitos de dados. Por isso, é 
importante você pesquisar o Guia da Modelagem de Dados: introdução & modelo 


conceitual, de Felipe Almeida. 
Pesquise sobre a ferramenta Vertabelo, citada neste tema. 


Visite o portal DB-engines para ver o ranking, atualizado mensalmente, sobre o uso de 


SGBDs. 
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